We live in interesting times for Java; I think it’s safe to say that Java, as a platform, has changed more in the last year than it had in the preceding five.  The session I’ll be presenting at JAX London in October is titled, “All the way to 11: Delivering new features in the JDK”. In this, I will talk about the current state and future directions for the Java platform. This article gives a few thoughts on where we are right now.

Last year, JDK 9 was finally released after a series of delays.  This release included a somewhat contentious feature, the Java Platform Module System (JPMS).  I’ve given a lot of presentations both to customers and at conferences since then, and it’s given me a chance to poll a broad cross-section of Java developers about their Java use.  What’s become clear is that adoption of JDK 9 and even JDK 10, (released only six months after JDK 9), is almost non-existent. The vast majority of developers are quite happy at the moment using JDK 8.  This version is stable, secure and includes functional programming elements not seen before in Java.

There are two reasons that a new version of Java, which would typically attract a number of early adopters is not proving a hit.

Firstly, there is a major change in strategy for the development of the JDK.  In the past, developers have been reasonably confident that code developed on one version of Java will run on later versions without change.  True, this has not always been the case. JDK 1.4 added the assert keyword, and JDK 5 added enum, which meant you couldn’t use these as variable names anymore.  Neither of these changes broke much code, and the changes required to get your application working again were trivial. There are a couple of other things that have changed along the way, but I’ve taken code compiled on JDK 1.0 and run it without change on JDK 8.  There really aren’t many development platforms that can say that.

One of the key reasons for this level of backward compatibility has been that new APIs and features have been added to Java, but nothing has been removed.  This, despite nearly 500 API elements having been deprecated since JDK 1.1. Whilst this is good for moving applications to newer versions of the platform without change, the technical debt of the JDK itself has become unmanageable.  The decision was made that, with the JDK now using JPMS it was time to start removing antiquated features as well as adding new ones.

The basic idea of JPMS is to divide the monolithic core libraries (which have grown from roughly 200 classes in JDK 1.0 to 4,500 in JDK 8) into more manageable pieces.  By doing this, it is possible to create Java runtimes tailored to a specific application, only including the modules required by the application. Given the popularity of developing and deploying applications as a set of microservices, this is a very sensible idea.

JPMS also includes a second major change, which is the encapsulation of all internal JDK APIs.  These are APIs not intended for general use; there is no public documentation for these APIs and developers have always been explicitly warned not to use them.  They have also been warned that these APIs may be removed without notice.

The reality is that, whilst most Java application developers don’t use these APIs, those who develop frameworks and libraries often do.  This led to a lot of potential problems breaking many applications. The JDK developers reversed their stance on this and introduced a set of command line switches that enable applications to override the encapsulation.

The second and more substantial reason for the lack of adoption of either JDK 9 or JDK 10 is the significantly faster release cadence of the JDK.  Rather than planning a set of features that had to be completed before a JDK could be released we now have a time-driven model of a new release every six months.

Clearly, it is not feasible for Oracle to support all of these releases as their number will proliferate over time.  The decision was made to use a Long Term Support (LTS) model, that is similar to the one used by people like the Ubuntu community.  A new LTS release will occur every three years. To get things started, JDK 8 was classified an LTS, and the next one will be JDK 11.  When looking at migrating applications to a newer JDK, many developers have decided to wait for JDK 11.

Unfortunately, the logic behind this decision might seem sound but is missing some subtle announcements from Oracle regarding the availability of updates to the JDK.

In the past, we have been used to the current JDK having public updates and, even after the next release comes out a period of overlap for these updates.  This has varied from a little over a year to nearly three years, allowing users to migrate between JDK revisions at a time that is convenient for them. Testing and stability can be assured before the move is made.

That will no longer be the case.  Starting with JDK 9, public updates are only available until the next release of the JDK, i.e. six months.  Oracle has also switched to providing two binaries of the JDK: the traditional Oracle JDK under the Oracle Binary Code License and a new OpenJDK-based binary under a GPLv2 with classpath exception license.  As of JDK 11, the Oracle binary (that most people have been using for deployments) will only be available for development and testing. If you want to use the Oracle binary for a commercial application, you will need a support contract from Oracle, which has a cost associated with it.  Azul Systems provides an alternative build of OpenJDK called Zulu. This is a direct replacement that requires no coding or configuration changes to use. Community builds of Zulu are free to download and use, and there is a very reasonably priced commercial option (Zulu Enterprise) with timely security updates and bugfixes.

There are many great ideas for the future directions of Java.  OpenJDK projects like Valhalla for value types, Project Amber for simplified syntax and Project Loom for massive multithreading are just three.  Clearly, the Java platform is not standing still, and developers will want to continue to update to newer and better versions of the JDK. How quickly and easily that happens remains to be seen.